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ABSTRACT 


The  Naval  Postgraduate  School's  Graphics  and  Video  Laboratory  is  halfway 
through  the  first  year  of  a  project  in  support  of  the  Naval  Ocean  Systems  Center’s 
Unified  Networking  Technology  (UNT)  project.  NPS’s  goal  is  to  develop  real¬ 
time  computer  graphics  displays  of  network  status  for  that  project.  In  this  report, 
we  propose  (1)  an  appropriate  set  of  displays  (2)  a  user  interface  to  select  and 
modify  these  displays  (3)  an  architectural  design  for  this  display  system  (which  we 
have  entitled  UNETGRAF)  and  (4)  a  progress  report  on  UNETGRAF  develop¬ 
ment  to  date. 
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1.  INTRODUCTION 


The  Naval  Ocean  Systems  Center  (NOSC)  Unified  Networking  Technology  (L'NT)  project  is 
a  large  scale  feasibility  study  whose  goal  is  to  demonstrate,  during  FY1990,  a  highly  robust  and 
survivable  naval  battle  group  communications  networking  system  which  supports  data  and  voice 
in  broadcast  and  point-to-point  services  using  HF  and  UHF  media.  In  support  of  the  UNT  pro¬ 
ject,  the  Naval  Postgraduate  School’s  Graphics  and  Video  Laboratory  has  begun  developing  a 
real-time  computer  graphics  display  subsystem  for  UNT.  The  following  are  the  objectives  esta¬ 
blished  for  this  subsystem,  which  we  have  entitled  UNETGRAF  |ZYD87j: 

(1)  Determine  computer  graphics  displays  that  best  convey  in  as  rapid  a  manner  as  possible 
the  information  flow  and  message  routing  activities  within  the  UNT  network. 

(2)  Propose  a  user  interface  for  this  system  that  will  facilitate  the  use  of  these  displays. 

(3)  Develop  a  portable  prototype  UNETGRAF  system  on  the  NPS  Graphics  and  Video 
Laboratory’s  IRIS  graphics  workstations. 

Discussions  with  NOSC  personnel  |GRI87j  have  provided  sufficient  information  on  the  tasks 
and  environment  of  prospective  UNETGRAF  users  for  us  to  formulate  our  answers  to  objectives 

(1)  and  (2).  In  this  memorandum,  we  (1)  present  these  results  and  (2)  describe  the  architectural 
design  of  our  prototype. 

2.  METHOD  OF  STUDY 

Neither  UNT  nor  UNETGRAF  are  existing  systems.  Thus  the  starting  point  for  our  systems 
analysis  was  an  examination  of  UNT  requirements  specifications  as  set  forth  in  |CAS86|.  This 
reference  identifies  three  functional  modules  within  UNT:  Link  Controller  (LC),  Multinetwork 
Controller  (MC)  and  Network  Administrator  (NA).  Discussions  with  NOSC  personnel  (GRI87| 
confirmed  some  significant  inferences: 

(1)  MC  functions  correspond  closely  to  those  of  the  Network  layer  of  the  International  Stan¬ 
dards  Organization  (ISO)  Open  Systems  Interconnection  model. 

(2)  LC  functions  correspond  closely  to  those  of  the  Link  layer  of  the  ISO  model. 

(3)  The  NA  is  a  storage  module  that  manages  the  data  used  by  the  LC  and  MC  and  despite 
its  name,  does  not  perform  any  network  management  functions. 
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(4)  UNT  network  architecture  closely  resembles  that  of  a  distributed  packet  radio  network. 

Thus  the  ISO  Open  System  Interconnection  model  and  packet  radio  networking  have  pro¬ 
vided  the  framework  for  fitting  these  UNT  modules  into  a  more  familiar  context.  Within  this 
framework,  many  references  are  available.  [STA85|  contains  a  good  description  of  packet  radio 
networking  issues  including  distributed  routing  protocols  and  the  special  problems  associated  with 
mobile  network  nodes.  [HER82]  provides  a  highly  readable  introduction  to  packet  radio  network¬ 
ing  as  well  as  an  algorithm  for  solving  the  distributed  routing  problem.  ;TAN8l|  remains  a  stan¬ 
dard  reference  for  detailed  descriptions  of  each  layer  of  the  ISO  model. 

As  for  drawing  a  picture  of  an  operating  network  which  is  of  any  cognitive  value--here  we 
encountered  a  major  and  unexpected  hurdle  in  our  study.  Available  literature  on  graphics- based 
network  monitors  proved  to  be  minimal  and  the  one  such  system  we  were  able  to  examine.  Digital 
Equipment’s  DECNet  Monitor,  provides  some  high  level  views  of  connectivity  but  quickly  gets 
into  text-based  displays  as  one  descends  in  detail.  More  on  this  issue  of  "meaningful"  pictures  in 
the  Analysis  section  below. 

Finally,  user  interface  issues  seem  to  invite  emotional  debate  or,  at  best,  subjectivity.  We 
unapologetically  base  our  prototype’s  user  interface  on  Macintosh-like  principles.  These  are,  quite 
simply,  the  de-facto  standard  for  interactive  graphics  applications.  Our  rationale  is  more  fully  dis¬ 
cussed  below. 

3.  ANALYSIS 

3.1.  OBJECTIVES 

To  review,  UNETGRAF’s  objectives  are  : 

(1)  Determine  computer  graphics  displays  that  best  convey  in  as  rapid  a  manner  as  possible 
the  information  flow  and  message  routing  activites  within  the  UNT  network. 

(2)  Propose  a  user  interface  for  this  system  that  will  facilitate  the  use  of  these  displays. 

(3)  Develop  a  portable  prototype  system. 
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We  discuss  our  reasoning  and  results  for  the  first  two  objectives  below. 

5.2.  NETWORK  DISPLAYS 

The  ISO  model  defines  the  levels  of  detail  in  any  network.  Specifically,  the  network  layer  is 
concerned  primarily  with  routing  decisions  that  are  based  on  the  connectivity,  utilisation  and  error 
statistics  collected  on  the  activities  of  the  link  layer.  Within  UNETGRAF,  we  are  concerned  with 
depicting  the  activities  of  the  network  and  link  layers  of  a  packet  radio  network. 

Networks  have  traditionally  been  represented  by  directed  graphs.  But  directed  graphs  alone 
are  an  abstraction— a  mental  step  is  required  to  convert  vertices  and  edges  into  the  real  thing.  The 
UNT  network  consists  of  physical  radio  equipment  aboard  real  ships  and  aircraft  at  actual  loca¬ 
tions.  If  possible,  it  should  be  so  depicted. 

Displaying  network  nodes  in  a  proper  geographical  context  also  permits  the  effects  of  range, 
terrain,  weather  and  enemy  action  (e.g  ,  jamming)  to  be  more  easily  seen.  Though  the  network 
itself  cannot  be  expected  to  provide  location  information,  the  ship’s  combat  reporting  system  (i.e. 
NTDS)  provides  a  ready  made  source  of  positioning  data.  The  NTDS  display  with  its  familiar 
symbology  provides  an  excellent  initial  picture  upon  which  the  network  picture  can  be  overlaid. 
Selectable  network  routing  and  connectivity  overlays  provide  a  highly  usable  picture  to  anyone 
who  must  engage  the  enemy  in  electronic  battle. 

Correlating  a  UNT  network  node  with  its  matching  NTDS  contact  is  a  necessary  and  non¬ 
trivial  step  in  this  scheme.  Also  some  cost  will  be  involved  in  providing  real-time  NTDS  data  to 
UNETGRAF;  however,  the  realism  and  usability  of  the  resulting  display  offset  these  factors. 

Node  level  activities  (e.g.,  packet  counts)  represent  a  step  down  in  detail.  Their  depiction 
should  be  available  on  demand,  but  is  most  appropriately  displayed  in  a  window  that  can  be  called 
up  when  it  becomes  necessary  to  more  fully  analyse  routing  or  connectivity  problems. 

5.3.  USER  INTERFACE 

UNETGRAF  is  a  network  monitor  system,  not  a  control  system.  Thus  user  interaction  can 
>  be  limited  to  moving  about  on  the  network  display  and  going  up  or  down  in  detail.  In  particular, 

l 

i 


no  requirement  for  text  input  is  anticipated,  so  the  only  user  input  required  is  "picking"  done  by 
either  a  mouse  or  trackball. 

Menus  are  to  be  minimized.  Though  they  are  recommended  for  the  system  novice,  menus  are 
longwinded  and  frustrating  for  most  other  users.  Balancing  this  requirement  with  the  high  degree 
of  functionality  required  of  the  UNETGRAF  system  does  present  a  usability  challenge  for  the 
designer  of  the  user  interface.  The  answer  lies  in  establishing  several  "modes"  of  user  interaction. 

Ideally,  UNETGRAF  should  be  completely  modeless.  That  is,  a  specific  user  input  should 
not  have  different  results  depending  upon  the  systems  "mode"  or  state.  If  it  is  necessary  to  change 
modes,  a  positive,  continuous  and  easily  recognized  indication  of  the  mode  change  should  be  made. 
A  familiar  example  of  this  concept  is  the  Macintosh  MacPaint  application  which  provides  the  user 
with  a  "palette"  of  what  are  essentially  mode  changes.  For  instance  a  paint  bucket  fills  polygons, 
a  pencil  draws  lines,  etc.  A  selection  from  this  "palette"  highlights  the  selection  and  changes  the 
user’s  cursor,  providing  all  the  visual  cues  necessary  to  convince  the  user  that  the  system  is 
responding  consistently  to  his  input.  Such  techniques  are  now  accepted  standards  in  interactive 
graphic  applications  and  are  incorporated  within  UNETGRAF’s  user  interface.  (See  Appendix  B 
for  annotated  sample  displays.) 

4.  UNETGRAF  ARCHITECTURAL  DESIGN 

4.1.  OVERVIEW 

Since  UNETGRAF  is  presently  a  protype  system,  we  have  concentrated  our  design  effort  on 
inter-module  communication  rather  than  detailed  module  development.  The  issues  of  portability, 
evolution  and  repair  have  been  given  major  emphasis.  Specifically,  we  have: 

(1)  defined  "public"  record  types  for  individual  NTDS  contacts  and  individual  network  nodes. 
A  list  of  NTDS  contacts  is  maintained  by  the  NTDS  Storage  module.  A  list  of  network  nodes  is 
maintained  by  the  UNT  Storage  module.  See  Appendix  D  for  formats  of  these  records. 
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(2)  provided  each  module  with  the  minimum  set  of  "public"  functions  to  permit  inter-module 
communication  but  hide  (in  the  software  engineering  sense)  "private"  data  structures. 

The  subject  of  inter-module  communication  brings  up  an  alternative  to  the  single-process 
implementation  of  our  prototype.  It  is  likely  that  a  "production"  UNETGRAF  system  might 
instead  consist  of  several  cooperating  processes  which  individually  run  the  UNT  Storage,  NTDS 
Storage,  UNT/NTDS  Correlation,  and  User  Interface/Display  modules.  This  alternative  is  men¬ 
tioned  because  it  bears  on  the  subject  of  minimum  host  system  requirements  which  we  discuss 
briefly  below. 

4.2.  MODULE  DESCRIPTIONS 

Inter- module  Communication.  See  Appendix  C  for  a  high-level  view  of  module  interaction. 

UNT  Storage  Module.  The  purpose  of  this  module  is  to  (1)  maintain  statistics  on  link-level 
protocol  performance  and  (2)  maintain  current  information  on  network  connectivity  and  message 
routing.  Our  prototype  generates  and  updates  link-level  statistics  and  connectivity  values  by 
pseudo-random  number-based  functions.  Based  on  these  connectivity  values,  we  compute  and 
store  shortest  paths  between  all  pairs  of  nodes  in  the  network  using  a  variation  on  Djikstra’s 
shortest-path  algorithm  |HOR83j. 

NTDS  Storage  Module.  The  purpose  of  this  module  is  to  maintain  current  information  on 
NTDS  tracks.  Our  prototype  initially  reads  a  list  of  contacts  from  a  text  file.  The  update  process 
involves  randomly  selecting  an  existing  contact  for  a  random  course  and/or  velocity  change. 
Duration  between  updates  is  declared  as  a  constant. 

UNT/NTDS  Correlation  Module.  The  purpose  of  this  module  is  to  determine  the  proper 
display  symbol  and  position  for  a  network  node.  We  do  this  setting  up  tables  that  permit  UNT 
and  and  NTDS  records  to  be  cross-referenced.  In  the  present  implemention,  we  make  the  tractable 
assumption  that  the  NTDS  record  maintained  by  the  NTDS  Storage  module  (See  Appendix  B)  will 
contain  the  UNT  network  address, if  any,  of  the  NTDS  contact. 

Uicr  Interface  Module.  This  module  allows  the  user  to  select  network  overlays  to  the  default 


NTDS  display,  alter  the  default  NTDS  display,  and  move  between  the  network  and  link  level 
displays  of  the  UNT  network.  The  main()  function  is  included  in  this  module. 

Display  Modules.  See  Appendix  B  for  the  graphics  screens  generated  by  these  modules.  The 
Node  Detail  Display  module  is  not  yet  implemented. 

5.  UNETGRAF  SYSTEM  REQUIREMENTS 

UNETGRAF  does  not  require  three-dimensional  graphics,  shading  or  other  advanced  com¬ 
puter  graphics  features.  However,  a  considerable  volume  of  information  is  required  to  display  the 
real-time  workings  of  a  communications  network,  particularly  a  distributed  packet  radio  network 
in  which  rapid  reconfigurations  are  a  normal  occurrence.  When  this  network  picture  is  provided  as 
an  overlay  to  a  tactical  display,  peak  graphics  loads  are  even  higher. 

We  recognize  that  physical  constraints  should  be  imposed  as  late  as  possible  during  system 
development.  However,  our  work  with  the  UNETGRAF  prototype  has  convinced  us  of  some 
minimum  host  system  requirements: 

(1)  Font  building  and  editing  facilities  are  needed  for  the  specialized  characters  used  in  tacti¬ 
cal  and  network  displays. 

(2)  High  performance  graphics  hardware  is  needed  to  handle  the  graphics  loads  described 
above. 

(3)  Assuming  that  UNETGRAF  is  eventually  implemented  not  as  a  single  process  but  as 
several  cooperating  processes  (as  described  above),  a  multi-tasking  operating  system  with  adequate 
inter-process  communication  facilities  is  needed. 

6.  PROGRESS  REPORT 

UNETGRAF  development  is  on  schedule.  With  the  exception  of  the  Node  Detail  Display 
module,  all  modules  have  been  implemented  and  tested.  The  user  manual  and  detailed  prototype 
system  documentation  will  be  completed  by  15  June  1987. 
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7.  CONCLUSIONS 

We  have  described  the  network  displays  that  are  appropriate  for  depiction  of  UNT  status 
and  operation.  The  nature  of  these  displays  as  overlays  to  the  NTDS  display  has  been 
emphasized.  A  Macintosh-like  user  interface  has  been  proposed.  An  architectural  design  for 
UNETGRAF  has  been  described  and  some  features  of  the  current  individual  modules  discussed. 
Some  minimum  requirements  for  any  host  system  on  which  UNETGRAF  is  to  be  implemented 
have  been  stated. 
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APPENDIX  B  (SAMPLE  DISPLAY  SCREENS) 
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Figure  2:  Connectivity  "Overlay"  Screen 
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Figure  3:  Routing  "Overlay"  Screen 


APPENDIX  C  (UNETGRAF  HIGH  LEVEL  DESIGN) 


=>  "provides  information  to" 


Figure  4:  UNETGRAF  High  Level  Design 


APPENDIX  D  (RECORD  FORMATS) 


/*  structure  to  hold  information  about  an  NTDS  contact  * / 
typedef  struct  { 

int  index;  /*  position  in  the  contact  list  */ 

int  net_id;  /*  network  address  */ 

char  track_no|6|;  /*  NTDS  track  number  */ 
char  contact_desc[20|;/*  text  describing  contact,  eg  "enemy  air"*/ 
char  corr_char[2];/*  character(s)  in  specialized  ACDS  font  * / 
char  mod[4);  /*  text  describing  contact,  eg  "SPRU"  */ 

float  course;  /*  true  heading  of  contact  */ 

float  speed;  /*  velocity  in  knots  */ 

float  gridx;  /*  position  on  NTDS  grid  */ 

float  gridy;  /*  position  on  NTDS  grid  */ 

float  DRx;  /*  current  x  position  based  on  DR  */ 
float  DRy;  /*  current  y  position  based  on  DR  */ 
float  track_hist[120|[2|;  /*  stores  last  120  track  positions  with 
an  x  and  a  y  coordinate  */ 

int  min  no;  /*  length  of  history  for  this  contact  */ 
int  track  flag;  /*  determines  if  track  history 
is  displayed  or  not  */ 

int  circle  flag;  /*  determine  whether  or  not  to  display  the 
contact’s  uncertainty  circle  */ 

int  uptime;  /*  elapsed  time  between  update  n  and  update  n-*-l  */ 
int  updated;  /*  TRUE  if  this  report  is  newly  updated  */ 

}  contact  report; 

/*  structure  to  hold  information  about  a  UNT  network  node  */ 
typedef  struct 
{ 

int  net  id;  /*  network  address  */ 
short  index;  /*  position  in  the  nodelist  */ 

short  unt;  /*  boolean  indicating  whether  node  is  UNT-capable  (store-and-forward  capable)  */ 

/*  rest  of  structure  to  be  implemented  with  Node  Detail  Display  module  */ 

}  node  report; 
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